如何让高并发低延时的推荐系统能使用更多的算力 ？

前文提到，我们估算用一个10B的模型去服务推荐系统，毛利也能满足平台经营需求。而实际上大部分推荐主场景的模型尺寸应该在0.1～0.01B附近。这个GAP背后，最关键的就是推荐系统的算力利用效率极低，从MFU就能体现出来。算力利用效率低下的核心原因是：#card

• 过去的推荐系统不是端到端的，而非端到端系统的算力效率会持续恶化。

业务迭代会增加各个模块，如召回/粗排/精排/重排的逻辑复杂度。

• 大部分成熟的推荐系统都不是单目标的，以短视频场景为例，#card

  • 会有用户体验相关的：互动/观看时长/VV，

  • 社区生态相关的：作品时效性/分阶段作者曝光占比/

  • 社区自治的比如营销感控制/负面情绪控制，

  • 创作相关的：发布作品活跃度/开播活跃度等。

• 在实际推荐系统的发展过程中，大部分的业务迭代流程是：#card

  • a. 根据业务意志or判断定下A/B量化目标

  • b. 在召回/粗排/精排/重排等各个模块施加干预

  • c. 哪个地方干预提升的A/B多，哪个模块就做对应的改动。

• 长久以往，推荐系统变得越来越复杂，每个模块都充满了各种奇怪和不可维护的逻辑。经常会出现一个launch review上线的时候有增益，过段时间下线它，又取得了一次收益，”双赢“！。

• 另一方面，由于如此多的业务目标，慢慢的一个模块内也会开始出现组织分工问题，大家会开始在一个环节内并联增加或者串联增加模块。

  • 比如一个粗排模块，可能会有并行多个粗排模型，它们在不同的人手里维护，为不同的业务目标服务。

  • 前后可能也有多个粗排阶段，这个逻辑排一次，另一个逻辑再排一次。在这么复杂的系统下，如果看机器的OpEx成本，其实大部分钱和系统Latency空间都没花在模型计算上，大部分的金钱成本和latency资源都花在了通信和存储上。

• 如果把这些考虑进去，大部分公司推荐系统的MFU恐怕连1%都达不到。

非端到端系统中各个模块的解空间限制下，单模块模型结构的设计也会越来越复杂。

• 即使我们只考虑单一模块，以推荐系统里算力最集中的精排为例，这些模型自己的MFU也不高。#card

  • 一年前我从业务领域回来接手模型团队，看到我手的精排模型在A10上MFU只有个位数，心情挺复杂的。

  • 这个模型和推荐同行比应该不算落后，不谦虚的说可能还比较先进。

• 但是一个在A10上都只能达到个位数MFU的模型在这个时代是极其落后的，意味着推荐落后于算力发展的红利，要知道LLM在H00上训练MFU都能到40-50%（不考虑fp8的情况）。#card

  • 这背后的原因也很简单，在互联网增速放缓后大家都在降本增效的背景下，总想着算力成本不增长的情况下提升模型效果。

  • 而算法同学一般算不清楚每年单位算力的成本会下降多少，只能约束自己计算FLOPs不要涨太多。

  • 那我们的模型，就只能变成各种奇思妙想的结合体，模型结构极其复杂，各种模块堆叠，到最后，模型图都很难画出来，一个团队可能只有少数几个人知道完整的模型长啥样。

  • 复杂的模型结构会让硬件花费大量的时间去做kernel调度，产生大量的非计算耗时，外加模型本身计算FLOPs不够大，自然MFU就低了。一个用不好算力的模型，不会是一个好模型。

如果我们去做一个端到端的推荐系统，一个系统只有一个模块就完成推荐结果的运算。我们就有机会把模型做简单，把模型做大，并且系统复杂度劣化的速度急剧减慢：#card

• 端到端系统下，没有链路一致性的问题，模型的影响被极致放大，好坏都赖自己。迭代过程中模型本身的作用和受关注度被放大，更有可能帮助模型迭代走向正轨。

• 简化的系统下，latency和计算成本资源都集中给模型，我们有机会把模型做得更大，MFU更高，形成良性迭代循环。

• 单模块的系统，不会出现链路不一致的寻租空间，大家更难在系统里增加一些能实现“双赢”（上线有收益，下线再拿一次收益）的变更，系统劣化速度就会减慢。

事实上，端到端的系统还有两个优势：#card

• 我们更有可能做出符合scaling law的模型，这个放在后面讨论。

• 同时，端到端的系统，强化学习才有可能发挥真正的作用，推荐的业务迭代会变得更简单。

  • 业务团队只需要定义清楚“什么是好的推荐结果”，并不断的迭代这个好的标准就行了，让强化学习来指导这个端到端的推荐系统。

  • 非算法同学不再需要理解召回/粗排/精排，以及各个模块的工作机制，深入链路里施加干预，能进一步保持系统的干净优雅。